feat(pages): show and edit grid pages of an application - #3215

Part of #3099, on top of #3214 (widget dialog). An application gets a page bar under its description, and the people who manage it can add grid pages and arrange widgets on them. The start page still lists its tables and views as before; #3216 shows it as a grid page too.

Size: 1453 lines: 1094 code and 359 tests.

What changes

• The page bar shows the start page first, then the grid pages in the order they were added, each with its icon. It follows the WAI-ARIA tabs pattern: a tablist with one tab stop, the arrow keys, Home and End move between tabs, Enter or Space opens one, and each tab has aria-selected and aria-controls pointing at the page panel, which is labelled by its tab. In a right-to-left language the arrow keys follow the reading direction.
• Adding a page asks for a title, an icon from the named icon set, a technical name and a description. The technical name is optional; the form checks it like the server (lower case letters, digits and underscores, starting with a letter) and refuses the page_<number> form the server keeps for itself. Without one the page gets page_<id>.
• A grid page shows its widgets for everyone who can open the application. People who manage it get Edit page, Edit page details and Delete page.
• Edit mode works on a copy: add a widget, configure or remove one, drag and resize, or move and resize from the widget's menu with the keyboard. Save sends all widgets at once through PATCH /api/2/contexts/{contextId}/pages/{pageId}, Cancel drops every change, and leaving the page or closing the tab with unsaved changes asks first.
• Deleting a page asks for confirmation; its tables and views stay in the application.
• Routes: /application/{contextId}/page/{pageId} opens a grid page.
• Who sees edit controls: the owner of the application, the same rule the existing Edit application dialog uses. The server checks manage access on every page endpoint itself (feat(api): pages and widgets on api/2 #3133); a sharee who calls them gets a 403.

Where else applications show up

Applications and their pages have no public share page, and the Smart Picker and reference widgets only cover tables and views, so there's nothing to wire up there.

How it was tested

On Nextcloud 34 with PostgreSQL:

• Playwright context-grid-pages.spec.ts: adding a page with a title, icon, technical name and description, adding a header and a table widget and finding them after a reload, Cancel drops changes, a sharee sees the page read-only and gets a 403 on PATCH, a table removed from the application leaves its widget asking for a new one, and moving and resizing a widget from its menu
• Cypress component tests ContextPageBar.cy.js (order, one tab stop, arrow keys, Home and End, add only for managers) and ContextPageForm.cy.js (technical name checks, keeping an automatic name)
• npm run lint, npm run stylelint and npm run build
• no PHP changes

🖼️ Screenshots

	Desktop (1400 px)	Phone (420 px)
A grid page
Editing the page
Adding a page

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔙 Backport requests are created or not needed: /backport to stableX.X
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI